home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-nasreq-nasrequirements-01.txt
< prev
next >
Wrap
Text File
|
1993-07-08
|
34KB
|
989 lines
INTERNET-DRAFT John Vollbrecht
Allan Rubens
Glenn McGregor
Larry Blunk
Richard Conto
Merit Network, Inc.
July 1993
Expires January 1994
Network Access Server
Proposed Requirements Document
Status of this Memo
This document is written as input to the Network Access Server
Working Group. It describes a Network Access Server and its role in
providing temporary access to a network. The document focuses on
needs for authentication, authorization and accounting support.
This revision of the document is still very much of a working
document. The document includes an overview of NAS requirements, a
description of the authentication and authorization environment that
a NAS is expected to interact with, a brief architecture description,
and a set of requirements matched with the architecture. The
requirements are still at a fairly high level and need details filled
in.
New concepts introduced in this version include a "helper" that acts
as an intermediary between the NAS and a variety of authentication,
authorization and tracking servers, and the idea of having a
"connection server" which could manage connection dialog for the NAS
and use a refined Telnet redirect to request the NAS telnet client to
connect to the appropriate destination
In addition, appendices deal with authentication, authorization, and
useage tracking issues as they apply to the NAS.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
NAS Requirements [Page i]
INTERNET-DRAFT July 1993
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.'' Please check the 1id-
abstracts.txt listing contained in the internet-drafts Shadow
Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any
Internet Draft.
NAS Requirements [Page ii]
INTERNET-DRAFT July 1993
1. Introduction
This document defines a set of requirements for a class of devices
referred to as Network Access Servers (NAS's). The term "Network
Access Server" is used instead of the more conventional term
"Terminal Server" as it more accurately describes the devices of
interest. This is written as input to the NAS requirements working
group of the IETF.
A Network Access Server (NAS) is a router or terminal server which
provides temporary access to a network. It can provide access for
both traditional "dumb terminals" and terminal emulators as well as
workstations, PC's or routers utilizing a serial line framing
protocol such as PPP or SLIP. Thus a NAS can provide connections to a
single user, to a network or subnetwork, or to interconnected
networks. The entities that use the NAS to connect to a network are
called Network Access Clients (NACs).
The NAS may be a system dedicated to providing temporary network
access, or it may be a part of a system which has other capabilities
as well. For example a workstation with a set of dial-in lines could
provide NAS functions.
The physical attachments to a NAS, which are used for temporary
connections, will typically be dial-in modems attached to local phone
lines, but could also be a hardwired connection supporting ISDN,
frame relay, or other switched (virtual) circuit services.
The purpose of this document is to define the requirements for
functions and services that a NAS should provide to both its
administrators (the people responsible for deploying and managing the
NAS) and its clients (the PCs, workstations and routers that connect
to the network through the NAS).
Many of the requirements of a NAS are identical to what is required
of a router. In fact a NAS can be viewed as a special class of
router, one in which the "neighbors" are not permanently attached.
When an attachment request is received, the NAS must insure that the
new "neighbor" is authorized to attach. This is contrasted with a
conventional router where a "neighbor" is permanently connected.
The application of this model to the character stream ("dumb
terminal") case requires that a "packetization" process convert
between the character stream and packet formats. In this case the
"neighbor" of the router is the packetizing client. A typical
packetizing client would be the Telnet client. The figure below
shows a model of this.
NAS Requirements [Page 1]
INTERNET-DRAFT July 1993
NAC network
attachment internal packet attachment
process(es) interfaces router(s) process
_______________________________________________________
| ________ |
| | | |
character | | Telnet | |
mode -----|-----| Client |\ |
| |________| \ |
| \ _____________ |
| \_()_____| | ________ |
| | | | | |
| | ROUTER |__|Ethernet|-|--
| ________ --()------| | |________| |
framed | | | / | | |
input ----|-----| PPP |/ |_____________| |
| |________| |
| |
| |
|_______________________________________________________|
Figure 1 NAS structure
In the above model there are NAC attachment processes which are
responsible for handling incoming data. Not shown, but necessary for
dial-in async input, is a process which will switch input to the
appropriate input process (e.g. a way to distinguish between a
character stream input and PPP input at the time a connection is
initiated). The figure shows two user attachment processes, but
there could be many different ones to support SLIP, ISDN, etc.
The internal router interface is the point where service
authorization is implemented. Here routing configurations, packet
filters and such are applied. The implementation of these may be
different at a PPP interface than at a Telnet Client interface. For
example, a PPP interface would restrict packets by applying filters
to each packet, while the Telnet interface might check for access
privileges only when it is establishing a TCP connection.
The router process forwards packets. There may be several processes
which route packets, each using different routing protocols. It is
likely that a NAS will route other protocols, such as IPX, CLNP or
Appletalk, in addition to IP.
The network attachment process is similar to the framed input
attachment process, except that it is configured as part of the NAS,
and its capabilities are not modified with new connections. The
network attachment process could support an ethernet connection, as
NAS Requirements [Page 2]
INTERNET-DRAFT July 1993
shown in the figure, a dial-out PPP connection, a synchronous serial
line, or some other network attachment mechanism.
(Note that if the network attachment is via a dial on demand port,
the NAS must be configured to know which remote router(s) to dial for
network connection. If a remote router dials into the NAS, then the
NAS can treat it similarly to any other dial-in port except that it
must set up routing to the network itself, and will probably require
mutual authentication between routers)
2. NAS Environment
A NAS can be used in a wide range of environments. It could be a
front end for an individual host, it could provide access to a LAN
for a limited set of users. The case we are interested in is where
it provides a large community of users belonging to a number of
different organizations with access to a network which interconnects
hosts from a number of organizations.
This is the case where a regional IP network provides dial-in access
for its users. The dial-in access allows connection to the regional
net and through it potentially to other networks on the international
Internet. The regional might provide dial-in access at a number of
geographic locations in order to limit costs of dialing.
As described here, the user (terminal, workstation or router) is the
Network Access Client (NAC). The NAC requests to be connected to the
network, and the NAS accepts or rejects the request. The NAC must be
authenticated and authorized by servers which can typically only be
reached through the NAS.
A NAS may want to identify a NAC by doing an authentication check at
the NAC's home organization. Once the NAC is authenticated, it may
also be desired to check the network capabilities for which the NAC
is authorized. The sort of capabilities a NAS provides include
protocols for access (e.g. PPP, IP, IPX, dumb terminal, telnet,
rlogin), what addresses are accessible from the NAC's port, and other
NAS specific functions that may be provided. This does *not* include
limits on what print servers, file servers, or other host
capabilities may be supported, other than by possibly restricting
access to destination addresses at which the servers reside. A NAS
is a Network Access Server, not a frontend to a set of servers or
hosts.
In the envisaged environment a NAS will need to authenticate a NAC at
the authentication server supported by the NAC's organization. Each
NAS Requirements [Page 3]
INTERNET-DRAFT July 1993
organization may support a different authentication mechanism. Some
may use Kerberos, some may use Unix password files, some may have
other mainframe based authentication mechanism, and others may use a
Public certificate system. A NAS will need to be able to interact
with whatever authentication servers are used at different
organizations. It is not reasonable to expect that an organization
will move tens of thousands of userids and passwords to a different
authentication system to allow the regional to use a NAS that
supports only a particular authentication mechanism.
Authorization servers will be run by the organization running the
network, and may be more closely tied to the NAS. For authorization
the NAS may also need to interact with authorization servers at the
NAC's home organization to be sure the NAC is authorized by its own
organization to uset the NAS. It is desirable for the NAS to use
some "standard" authorization service.
Finally, a NAS will need to track useage for Accounting and auditing
purposes. Accounting information will need to be forwarded to a
number of different auditing/billing systems supported by different
organizations.
3. NAS architecture
A NAS consists of a set of ports which connect Network Access Clients
and networks. NAS processes take data from the ports,
packetize/depacketize it appropriately, and route packets between
ports. This is what is shown in Figure 1.
In addition, a NAS has "management" processes that are needed to
perform the following tasks
1. NAC identification and authorization
2. Per NAC useage tracking for auditing and accounting
3. collecting and reporting performance and load measures
4. debugging
5. configuration of NAS
6. loading and dumping
7. call initiation dialog
8. stuff that we have forgotten or not thought of yet
A NAS will hopefully be an inexpensive box. The processes that
support NAC identification and authorization and useage tracking may
be complicated, mostly because of the number of ways different
organizations may choose to do these. Thus a NAS might have to
implement Kerberos, Unix password support, and Public Key Certificate
NAS Requirements [Page 4]
INTERNET-DRAFT July 1993
authentication depending on the user. To make this simpler for NAS
suppliers to implement and support, a "helper" process is included in
the architecture. The "helper" interfaces to the different
authentication, authorization and useage tracking systems. It
communicates with the NAS using a simple standardized protocol.
In addition to making implementation and support simpler, it provides
a mechanism by which a NAS can adapt to evolving authentication and
authorization standards. The "helper" can also be adapted to perform
additional functions that might not be justified in a standalone NAS,
for example it might support custom connection dialogs for character
stream NACs.
The "helper" may reside physically on the same hardware as the NAS,
or it may be on a remote workstation. It is possible that if the
NAS/helper protocol becomes widely accepted that public domain
versions of "helper" implementations will become available to
interface with most authentication and authorization servers.
The following figure gives a view of the proposed NAS architecture.
The numbers in this diagram indicate the section below which
describes the particular interface.
/ useage tracking servers
/
/- authorization servers
/
/--- authentication servers
4.3- "helper" -
/
NAC --- 4.1 - NAS 4.2-- Network
|
4.4
\------- call initiation - (remote selection)
\
\----- performance statistics
\
\---- debugging
\
\-- config
\
\ load/dump
NAS architecture elements
NAS Requirements [Page 5]
INTERNET-DRAFT July 1993
4. NAS requirements
The following details requirements for each of the interfaces
indicated in the above architecture. The sections are not complete
and need to be completed/reviewed by the nasreq working group.
4.1. NAS - NAC interface
4.1.1. Detecting type of call
Need a way to detect at call initiatiation whether the NAC is doing
character stream or PPP input. (details of one way of doing this
will be provided)
4.1.2. NAC Authentication (see appendix for overview)
4.1.3. Character Stream authentication
NAC doing initial connection with character stream data should be
able to authenticate using
-id/pw
-smartcard
-other?
4.1.3.1. PPP authentication
authentication using PPP should be supported via
-PAP
-CHAP
-Kerberos Challenge
-Public Key Challenge
4.1.3.2. Mutual Authentication
The NAC may need to confirm that it has connected to the correct
network. The NAS will need to have a certificate or token that it
can show to the NAC which proves the NAS is acting for the network.
NAS Requirements [Page 6]
INTERNET-DRAFT July 1993
4.1.4. Character Stream clients
A NAS may support telnet, rlogin, tcp passthru, other
4.1.5. PPP input process
PPP input process should support IP
may support IPX, Appletalk, Vines, OSI, bridging
4.1.6. IP Address assignment
4.1.7. Per Packet Address filtering
4.2. NAS - Network interface
4.2.1. Interface - ethernet, token ring, FDDI, synchronous PPP,
4.2.2. Protocols - IP required, IPX/ Appletalk/ Vines/ OSI
4.2.3. Router Process
Must support IP routing.
RIP, OSPF
4.3. NAS - helper interface
This is being specified as part of the working group process. The
protocol must allow information to be transferred between NAS and
"helper" reliably, passwords must not be sent in the clear.
"Must not present security exposure greater than already presented on
NAC/NAS interface".
4.4. Management processes
4.4.1. SNMP
The NAS must support SNMP. Standard MIB2 entries, plus additional
support for hunt group utilization. Should be able to support modem
mib.
It may be requested that configuration information, such as additions
or deletions from packet filtering lists, be done via SNMP
NAS Requirements [Page 7]
INTERNET-DRAFT July 1993
4.4.2. Debugging
The NAS should support an out of band access capability that allows
access to local debugging tools.
4.4.3. Configuration
The NAS should be able to be reconfigured over the network without
rebooting.
4.4.4. Load/dump
There needs to be a secure load/dump mechanism.
4.4.5. Call initiation
At call set up using dumb terminal mode, authentication and
authorization of the NAC to the NAS should be independent of
authentication and authorization of sessions to remote hosts. For
example, a NAC would have to give a password and id to establish that
it is ok for it to connect to a local telnet client. The NAC would
then telnet to a remote host which would also require the NAC to
identify itself.
A NAC/NAS session may support multiple packetizing sessions. For
example a NAC might establish a connection to a NAS and then connect
to serveral telnet client processes, each of which connects to a
different remote host.
At call set up the NAS may pass the connection to a "connection
server" which could present an individualized connection/help menu.
The connection server could then use a "cleaned up" telnet redirect
message to have the NAS extablish a connection to the appropriate
host/port. Note that authorization to make the connection would need
to be applied before the NAS actually initiated it.
This requires clean up of the telnet redirect definition.
The security implications of this have not been well thought out yet.
It is important that a NAS not accept a redirect request from anyone
except the "connection server" or its agent.
NAS Requirements [Page 8]
INTERNET-DRAFT July 1993
Appendix A Authentication Overview and Alternatives
1. NAC/NAS authentication
NAC/NAS authentication will be done in one or more of the following
ways.
a) userid/pw - this is the most primitive, and has the pw in
the clear between NAC and NAS. It is by far the most common
mechanism
at this point.
b) one-way challenge authentication - this authenticates the NAC
to the NAS using a challenge/ challenge response algorithm. Three
algorithms are discussed below.
c) mutual authentication - the NAC is authenticated to the NAS and
the network/NAS is authenticated to the NAC. The algorithms for
this may need some further work, but three approaches are discussed
below.
The assumption is that a NAS vendor will implement one or more of
these authentication mechanisms and users will buy what is best for
their application. The intent is to specify what protocols will be
used at each level so that implemetations from different vendors of
that level will interwork.
The following descriptions are oriented to using PPP authentication
mechanisms. Adapting these to character stream input is left for a
later document.
The nasreq working group should pass responsibility for detail
formulation of the PPP protocols to the PPP working group or to a
joint PPP/NAS/security group.
The following discusses the authentication options in more detail.
a) passing userid/pw from NAC to NAS. This can be done for character
stream connections using a prompt sequence. For PPP it will be done
via PAP.
The protocol sequence (for PPP)
NAC->NAS: userid/pw
NAS_>NAC: ACK/NAK
The NAS can take the userid/pw combination and access almost any
NAS Requirements [Page 9]
INTERNET-DRAFT July 1993
authentication server as proxy for the NAC.
This has the problems that the pw is in the clear betweent the NAS
and NAC. The NAS also has the pw in memory for some time so it may
be vulnerable to other attacks.
On the other hand, it is simple, it exists now, and it is better than
nothing (at least for the short term).
b) a challenge protocol to authenticate NAC to NAS
This is the class of authentication that includes CHAP. With this
approach the protocol sequence between the NAC and NAS follows the
model below.
NAC->NAS: userid
NAS->NAC: challenge
NAC->NAS: challenge response
the challenge may be repeated periodically.
This eliminates the password in the clear problem. The CHAP
implementation is done in PPP, and the others need better definition,
but appear not to be a big change to PPP.
Three different challenge /response mechanisms have been suggested
1) CHAP - NAC and NAS know a common secret and use it to generate and
evaluate the response to a "challenge". In PPP implementations the
expectation is that the NAS may send the challenge information and
response to a third party CHAP server which keeps the common secret
for each NAC and returns a yes or no response back to the NAS.
2) Kerberos version - NAS goes to Kerberos server to get a session
key to be used by NAS and NAC. The NAC gets its key n in the
challenge sent by the NAS, encrypted in its key. The challenge
response is generated with the received key.
The intent of this is to allow the NAC to use a Kerberos server that
is available at his site in the authentication process. It means
that it can have one secret to maintain and remember rather than
many.
One sequence that might be used to support this is as follows (the
statements with * at the start are the actual NAC/NAS protocol
statments):
NAS Requirements [Page 10]
INTERNET-DRAFT July 1993
*NAC->NAS: userid
NAS->authS: userid,NASid
authS->NAS: {sesskey,userid,{sesskey,NASid}*kNAC}*kNAS
NAS: decrypt using its key (kNAS), keep session key, userid
*NAS->NAC: challenge, {sesskey,NASid}*KNAC
NAC: decrypt using its key (KNAC)
respond to challenge using sesskey (common session key)
*NAC->NAS challenge response
NAS: uses saved sesskey and userid to validate the response
*NAS->NAC ACK/NAK
3) Public Key certificate version - similar to Kerberos but uses
Public key certificate.
The intent is to allow use of public key certificate distributions
systems to authenticate NAC to NAS. The NAC uses his private key to
"sign" a challenge, which is then checked by the NAS using the NAC's
public key.
The following indicates one way this could be done.
*NAC ->NAS: userid
*NAS ->NAC: challenge
*NAC ->NAS: challenge*NACprivate-key
NAS: get certificate with public key of userid
verify NAC's response
*NAS ->NAC: ACK/NAK
c) mutual NAC / network authentication - In this case the NAC and
network (via the NAS) mutually authenticate each other. This
mechanism needs further definition, and should probably be directed
to a group with more depth in security issues.
NAS Requirements [Page 11]
INTERNET-DRAFT July 1993
One approach to mutual authentication is to run the algorithms twice,
once in each direction. For CHAP with a shared secret that might be
workable. However, it seems that it should be possible for the NAC to
authenticate to a "network" rather than a specific NAS. In fact the
NAC may have no idea which NAS it is calling. Typically a list of
dial-in numbers would have a provider name rather than a NAS id
associated with it. A dial hunt group might be spread accross
several NASs.
The following are meant to give an idea of how something like this
might work rather than be a definitive design. However in the
interest of stimulating discussion, the following are presented.
1) mutual authentication with CHAP
*NAC->NAS: userid,netchallenge
NAS: use common secret to generate response to netchallenge
*NAS->NAC: userchallenge,netchallenge-response
NAC: use common secret to generate response to userchallenge
*NAC->NAS: userchallenge-response
*NAS->NAC: ACK/NAK
note that this fits the same protocol framework as the one way
authentication. If the NAS goes to a third party CHAP authentication
server then all NASs that use that server will look the same to the
NAC.
2) mutual authentication with Kerberos
In this mechanism the assumption is that the NAS gets a ticket
granting ticket for a ticket granting server that knows all NACs.
*NAC->NAS: userid, netid,netchallenge
NAS->authS: userid,NASid
authS->NAS: {ksess,userid,{ksess,NASid}*kNAC}*kNAS
NAS: decrypt using kNAS, keep ksess, userid
use ksess to create reply to netchallenge
*NAS->NAC: {ksess,NASid}*kNAC, netchallenge-response, userchallenge
NAC: decrypt using kNAC, keep ksess, NASid
use ksess to evaluate netchallenge-response
use ksess to generate response to userchallenge
*NAC->NAS: userchallenge-response
*NAS->NAC: ACK/NAK
This again is the same message sequence as before, but with different
content in some of the messages. If the authS knows both the NAS and
NAC and will not authenticate anything other than a NAS having the
NAS Requirements [Page 12]
INTERNET-DRAFT July 1993
NAC (somehow - for futher study) check to see that the NAS is in fact
authorized by the network to act on its behalf.
3) mutual authentication with public key certificates
*NAC->NAS: userid, netid, netchallenge
*NAS->NAC: userchallenge, netchallenge*NASK, NAS-net-certificate
*NAC->NAS: userchallenge*KNAC,
*NAS->NAC: ACK/NAK
In this mechanism, the NAS and NAC use their private keys to sign a
challenge. The NAS gets the public key of the NAC from a certificate
server. The NAS sends the NAC a special, to be designed, certificate
that includes the public key of the NAS signed by a network
certificate provider. It also certifies that the NAS is authorized
to act for the netid network. The NAC must know the public key of the
certificate provider ahead of time, or have some other way of finding
out.
NAS Requirements [Page 13]
INTERNET-DRAFT July 1993
Appendix B Authorization
1. NAS / network authorization
The NAS may need to be authenticated to a variety of authentication
and authorization servers in order to make
authorization/authentication requests for the NAC. This will be done
using standard authentication protocols. This needs more detailed
definintion.
2. Authorization of NAC
Once the NAC is authenticated, the NAS will need to determine what
the NAC is allowed to do. Two approaches to deciding what is
appropriate have been discussed.
a) Get a list of what the NAC is allowed to do and give it to the
NAS. This has been described as per NAC configuration.
b) Each time the NAC requests a new service (e.g. telnet to x.y.z)
ask a authorization server if it is allowed. This has been described
as the access control or authorization server approach.
3. Virtual networks
One major authorization requirement is to restrict a NAC's access to
a particular set of destinations on the network. For IP users this
is typically controlled by setting packet filters.
Some different approaches to how to set up and administer these
filters have been discussed. Having a set of filters that is unique
for each user gives the most flexibility, but could be very time
consuming and error prone for large populations of users from
different organizations.
Alternatively a number of named filter sets could be set up and each
NAC would request authorization to use one or more set. This can be
thought of as setting up a number of virtual networks which the NAC
may or may not be authorized to access. Currently this approach
seems to be favored.
NAS Requirements [Page 14]
INTERNET-DRAFT July 1993
Appendix C Useage Tracking/Accounting
A NAS must create tracking records to allow tracking each NAC/NAS
connection session. For each session there should be a unique
session ID which is included in the header of each record for that
session.
A tracking record should be generated at the time a NAC makes initial
connection to the NAS, when the connection is terminated, and for
special events during the session. Some of the special events that
need tracking records are
1) establishing a telnet/rlogin/etc connection from NAS client to a
remote node
2) terminating a telnet/rlogin/etc connection from NAS clientto a
remote node
3) checkpoints - same information as end of session records in case
an end of session record should get lost.
In addition to session records, tracking records should be generated
for NAS system events including:
1) NAS startup
2) unsuccessful connection attempts (note that if id/pw fails the id
should not be recorded to avoid recording passwords typed in out of
sync)
Tracking records should be sent to one or more collection servers.
Each record should contain character and packet counts, unique
session id, NAC id, NAS port, IP address, date-time of session start
and of record generation, frame and packet protocol types (e.g.
PPP/IP). Telnet/rlogin/etc tracking records will have as additional
information the destination address/port, client type, and userid.
This needs to be spelled out better in conjunction with ietf
accounting wg.
NAS Requirements [Page 15]
INTERNET-DRAFT July 1993
Authors' Addresses
John Vollbrecht
email: jrv@merit.edu
Allan Rubens
email: acr@merit.edu
Glenn McGregor
email: ghm@merit.edu
Larry Blunk
email: ljb@merit.edu
Richard Conto
email: rsc@merit.edu
all Authors may be reached as follows
Merit Network, Inc.
1071 Beal Ave
Ann Arbor Mi. 48109
Phone: (313) 936-3000
